home *** CD-ROM | disk | FTP | other *** search
- Path: comma.rhein.de!serpens!not-for-mail
- From: mlelstv@serpens.rhein.de (Michael van Elst)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Demo/game to OS friendly part II
- Date: 5 Feb 1996 10:44:59 +0100
- Organization: dis-
- Message-ID: <4f4jir$5rn@serpens.rhein.de>
- References: <john.hendrikx.47u5@grafix.xs4all.nl> <PETERM.96Jan29164036@tui.maths.irl.cri.nz> <4ek6bo$84n@xmission.xmission.com> <4ekl5d$51@serpens.rhein.de> <PETERM.96Feb1123338@tui.maths.irl.cri.nz> <4ep546$hpr@serpens.rhein.de> <PETERM.96Feb1205215@tui.maths.irl.cri.nz> <4eq5s3$mnn@serpens.rhein.de> <PETERM.96Feb5131910@tui.maths.irl.cri.nz>
- NNTP-Posting-Host: serpens.rhein.de
-
- peterm@maths.grace.cri.nz (Peter McGavin) writes:
-
- >Now, isn't a queue of gfx-operations simply a queue of messages (or
- >packets)? Wouldn't a straightforward implementation be that a
- >high-level gfx function sends a message to some handler task for the
- >bitmap?
-
- That would be a straight forward solution but I believe it would be
- pretty slow because of the amount of task switches.
-
- >Except some gfx calls would only construct a portion of a
- >message as a form of buffering, or simply return a status or
- >something.
-
- I think we can live without an extra server task. Each rendering
- device would have its own (limited length) queue. The queue should
- be large enough that a Blt function runs completely asynchronous.
-
- >Or do you propose hanging everything off interrupts, like
- >QBlit() (which would get messy IMO)?
-
- For the native graphics you would use QBlit() most often.
- You would also try to avoid the interrupt overhead for small blits.
- The cycles wasted in WaitBlit() could be less than the time spent
- for interrupts.
-
- Regards,
- --
- Michael van Elst
-
- Internet: mlelstv@serpens.rhein.de
- "A potential Snark may lurk in every tree."
-